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(54) Shared loop audio/video server system 

(57) A shared loop multimedia datastreaming server 
system is provided. A plurality of A/V servers have equal 
access to a pool of disk arrays interconnected in a 
shared loop architecture such as SSA or FC-AL Each 
server delivers a corresponding datastream from the 
loop through an isochronous broadband connection to 
appropriate A/V devices. The A/V servers are intercon- 
nected by a control loop such as an Ethernet link. An 
archive server also accesses the shared storage loop 
and an archive storage system. The archive server 
loads titles from archive to the loop as desired and 
serves as a backup A/V server A high availability control 
server cluster interconnects to the A/V server and the 
archive server to control resource management includ- 
ing distribution of titles on the loop and loading titles from 
the archive server and balancing the loads on the A/V 
servers. 
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the fiber channel loop 10-12 comes into play. The title T 
may be transferred over the loop 10-12, statically by an 
operator, e.g., not on demand, to a next disk controller 
22 and replicated as T* in one of the corresponding disk 
drives 23 associated with controller 22. tn this manner, 
an additional complement of video streams of the title 
may be provided by the controller 22 on line 24C. deriv- 
ing from the replication of title T on controller 22's disk 
drive as tne redundant title TV 

Several significant problems are associated with 
implementations of such video controller systems of Fig. 
1. First, it will be recalled that video titles require huge 
amounts of storage and thus the cost of disk storage 
19-23 is typically a major part of the cost of the entire 
system. Thus, in order to satisfy demand for video 
streams in excess of that which can be provided by a 
given controller 18-22. it is generally unacceptable to 
simply replicate the title as V on another disk drive in- 
asmuch as this requires redundant and expensive cop- 
ies of the data. An inherent weakness of the system of 
Fig. 1 relates to the fact that each controller 18-22 may 
only access its own set of respective local disks 19, 21 T 
23, necessitating transfers of titles across the ring 
10-12. 

Yet another problem associated with the systems of 
Fig. 1 is that even if the expense of replication of titles 
might somehow be acceptable, it can readily be appre- 
ciated that given a particular demand for titles, the ring 
10-12 may itself become congested in transferring video 
data from respective disk storages of one controller to 
that of another thereby adding unacceptable overhead 
to the process. Moreover the various disk drives 19-23 
typically may have a larger bandwidth than the number 
of streams which a given controller associated with the 
particular disk drive may be able to handle. Thus, in the 
system of Fig. 1 the bandwidth of the expensive disk 
drives is essentially constrained by the bandwidth of 
their respective servers and controllers in a number of 
streams 24A-24C which each respective controller 
18-22 may be able to deliver. The design of the system 
is inherently and expensively unbalanced in that each 
of the expensive disks should be "milked" to take ad- 
vantage of the full capability of its read head bandwidth 
without constraining it by its respective controller. 

In interactive video systems with differing mixes of 
demands of the various titles, in such a system as that 
of Fig. 1 it will be apparent that a daunting task arises 
for someone to be able to predict demand and prebal- 
ance clips on the various disk drives 19-23 to meet the 
varying loads and to reduce congestion on the arbitrated 
loop 10-12. In one such attempt to do so. systems may 
add a switch controller 11 seeking to balance in some 
intelligent fashion the distribution of titles across the 
disks 19-23. However, such systems are extremely ex- 
pensive due to switch logic for hundreds of disks 
and still exhibit the aforementioned problems of unbal- 
anced systems which can arise very quickly. Also there 
is a single point of failure so two switches must be pro- 



vided. In short, a significant problem of the system of 
Fig. 1 is that the expensive disk drives are local or pri- 
vate to their respective controllers and the fast fiber 
channel loops 10-12 are disposed on the front end of 
5 the system interconnecting the controllers 18-22 only to 
facilitate moving data over the arbitrated loop between 
processors. This gives rise to the undesirable less-bal- 
anced and more expensive characteristics of the sys- 
tem. 

io in yet another approach to solving the aforemen- 
tioned thorny problems, the system of Fig. 1 provides a 
crossbar switch 6 or other type interconnecting switch 
interposed between a plurality of disk controllers 30, 32, 
34 : and various disk arrays. 38 : 40. 42. 44. which have 

*5 stored therein the video data. Thus, unlike the system 
of Fig. 1 , the system of Fig. 2 enables any controller 30. 
32, 34, to access a title on any of the disk arrays 38. 40, 
42. 44. by means of the crossbar switches 36. Thus, 
while such a system avoids the expensive practice of 

20 maintaining redundant copies of titles in that any con- 
troller can access any disk, unfortunately in many appli- 
cations the cost per stream in a system such that of Fig. 
2 becomes prohibitive. This is a direct result of the ex- 
cessive cost of such high interconnect and redundancy 

25 crossbar switches 36. considering the fact that given the 
large number of datastreams, a correspondingly large 
number of the expensive crossbar switches 36 are re- 
quired. 



A shared loop multimedia datastreaming server 
system is provided. A plurality of A/V servers have equal 
access to a pool of disk arrays interconnected in a 

35 shared loop architecture such as SSA or FC-AL. Each 
server delivers a corresponding datastream from the 
loop communications through an isochronous broad- 
band connection or other dedicated line to appropriate 
A/V devices. The A/V servers are interconnected by a 

•to control network such as an Ethernet, Token Ring or oth- 
er link. An archive server also accesses the shared stor- 
age loop and an archive storage system. The archive 
server loads titles from archive to the loop as desired 
and serves as a backup A/V server. A high availability 
control server cluster interconnects to the A/V server 
and the archive server to control resource management, 
including initial load of stream requests to servers and 
requests to load titles on the loop and loading titles from 
the archive server and balancing the loads on the AA/ 

50 servers. 

Brief Description of the Drawings 

Fig. 1 is a functional block diagram of an audio/vid- 
ss eo server system of the prior art. employing fiber chan- 
nel arbitrated loops interconnecting disk controllers. 

Fig. 2 is a functional block diagram of yet another 
audio/video server system of the prior art employing 
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crossbar switches (or selectively interconnecting a grv- 
en controller to a desired storage device. 

Fiq 3 is a tunctional block diagram of one imple- 
mentation an audio/video server system of the invention 
employing a shared storage loop. 

Fig. 4 is a more detailed functional diagram of the 

system of Fig. 3. 

Fig 5 is a flow diagram illustrating the operation of 
the systems of Figs. 3 and 4 of the invention. 

nailed Descrir'i™ nf the Preferred Embodiment 



Turning now to Fig. 3. depicted therein is one im- 
plementation of an audio/video server system of the in- 
vention. In comparison with the prior art system of Fig. 
1 certain similarities are readily apparent. First, an ap- 
propriate switch such as an ATM switch 50 is provided 
interposed between a plurality of display terminals such 
as television sets 54 and a plurality of severs or con- 
trollers 56. 58. 60. Each controller is interconnected to 
the swrtch 50 by its respective data stream line 62. 64^ 
66 Also similar to the system of Fig. 1 . a plurality of disk 
drive arrays 70, 72. 74. 76, are provided wherein titles 
such as T are digitally stored therein. 

However a closer comparison of Figs. 1 and 3 re- 
veals a fundamental distinction. It will be noted that the 
fiber channel arbitrated loop I0-l2of Fig. ' 'd**™* 
with which interconnected the controllers 18-22 In con- 
trast in the system of the invention depicted in Fig 3j 
serial storage architecture (SSA) or fiber channel arbi- 
trated loop (FC-AL) 68 is provided interposed between 
the controllers 56-60 and the disk arrays 70-76. The im- 
portant significance of the introduction of the loop 6E ^be- 
tween the controllers 56-60 and the disk arrays 70-76 is 
that, unlike the case of the system of Fig. 1, these ex- 
pensive disk arrays, by means of the loop 68 are no 
longer dedicated or local to respective controllers^ but 
rather are readily available by means of the loop 6e to 

anv controller 56-60. 

Thus inoperation.ifatitleTisdesiredtobeviewed 

by a user on the display 54, this video stream .may es- 
sentially be provided by any of the controllers 56-60 from 
the same disk 72 on which the title T resides. The de 
mandmaythereforebese.vicedbythestreamfromd^ 

72 being delivered across loop 68 to controller 56. 
through line 62. switch 50. cable connection 51 to dis- 
play devce 54. Similar*, the path could be from ^disk 72 
through loop 68. controller 56. line 64. switch 50. cable 
connection 51 to display 54. In like manner, the demand 
could be serviced along the path from disk 72 through 
loop 68, controller 60. line 66, switch 50. cable connec- 
tion 51, to display device 54. 

More importantly, however, it is important to note 
that the demand for this same title T may be serviced 
simultaneously through the three aforementioned paths 
e g Through controller 56, 58. and 60) without neces- 
s,ta,ing the expense replication of the title on , another 
disk array 72. 74. or 76 (compare the case of the system 



of Fig. 1 wherein the title T on disk array 21 had to be 
replicated on disk array 23 as title T'). 

As will be recalled, the bandwidth of a given disk 
dr*e 70-76 typically may exceed the datastream han- 
s dling ability of a given controller 56-60. For ^ e ^ e 
bandwidth of the drive 72 may be able to delwer 60 or 
more datastreams of the title T, whereas a grver . con- 
troller 56, for example, may only be able to ] handle 30 
datastreams. It will be recalled that this problem is what 
,o gave rise to the necessity for replicating the ti tie or , a 
different controller in the system of Fig. 1 (so that this 
other controller 22 could deliver the additional required 
datastreams itself from its dedicated disk 23 on which 
the replicated title V was stored). However, it will noted 
>s in the system of Fig. 3, that this demand for data streams 
in excess of the capability of a grven controller may now 
be spread throughout a plurality of controllers without 
necessitating replication of the content itself, e.g., cop- 
ying the title T in an expensive and overhead -Mensrve 
20 manner to one or more of the remaining disks 74-76. As 
a result of this innovation, (unlike the case of Fig. i 
wherein the potential arose for congesting the loop 
10-12 with transfers of title data thereon to the various 
controllers) this burden need not be placed on the loop 
25 68 

' it will be appreciated that the various controllers 
56-60 must be coordinated and interconnected as in the 
case of the controllers 18-22 of Fig. 1. However, refer- 
ring again to Fig. 3, this control loop 52 may be provided 
30 by an Ethernet loop well known in the art rather than 
necessitating a high speed fiber channel loop £ in toe 
case of the system of Fig. 1 . The reason for this ,s ha 

the relatively slower loop connection 52 such as that 
providedby an Ethernet, may be adequate because un- 

3 5 Eke the case of Fig. 1 . a great deal of video data s no 
beingplaced upon the loop 52 (since essentially lis only 
performing the function of control and coordinating the 
various processors 56-60). Thus, the loop 52 need not 
be as high a performance loop as that of arbitrated loop 
40 1 0-1 2 in the case of the system of Fig. ] ■ 

in summary then, in the case of system vthe disks 
70-76 are shared by all of the processors 56-60 in a clus- 
ter Moreover, only as many drives 70-76 are required 
o h* titles as are required or limited by the bandwidth 
,5 of the parteular disk drive (e.g.. the number of video 
Learns that a grven disk can handle). This .s in recoj 

nrtion of the fact that modern day P^«f^^™; 
saturatequicklyintermsofthenumberofvideostreams 

they may handle whereas a given disk dr.ve 70-76 may 
so nevertheless have remaining bandwtfth i left over o 
service another such processor with the -dental video 
stream (e g.. the same title T). Also, in the system of Fig. 
3 bemuse any g*en controller can essentially access 
atSleTw'thsimiloverheadviatheSSAorFC-ALoop 

55 68, the demands to balance the titles over the , diskj r- 
rays are not as demanding as in the case of the system 

°' F Having now completed a high level description of 
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the system of Fig. 3 from which an understanding of the 
invention may be gained, reference is now made to a 
more detailed illustration of the system in Fig. 4 which 
will reveal in comparison many similarities to Fig. 1 . The 
essential elements of the system of Fig. 4 may be now 
be described. 

In the simplified illustration of Figs. 1-3. only three 
servers or controllers were shown. The invention is not 
intended to be so limited. Accordingly, in Fig. 4, one or 
a cluster of essentially any desired number of audio/vid- 
eo server computers 94- 1 08 may be provided which ac- 
cess a pool of disks via shared loops shown generally 
as reference numeral 110 looped in accordance with se- 
rial storage architecture (SSA) or fiber channel arbitrat- 
ed loop (FC-AL) standards. In a particular embodiment, 
although the invention is not intended to be so limited, 
1 to 32 computing nodes may be provided by the com- 
puters 94. 108, comprised of a corresponding 1 to 8 
CPUs : with 3 x ATM 155 megabyte adapters. 2 x SSA 
adapters or 4 x FC-AL loop adapters. 

An isochronous (e.g., guaranteed bandwidth) con- 
nection {implemented in the system of Fig. 4 as an ATM 
switch and network. 88) is provided between the servers 
94-1 08 and a set of audio/video devices 83 delivered by 
a broadband channel 82. In the alternative, analog out- 
put may be selected and provided in a conventional 
manner. These audio/video (A/V) devices 83 may in- 
clude, but are not limited to televisions, television control 
adapters (set top boxes) personal computers, and infor- 
mation kiosks. For generality, users of such AA/ devices 
83 may be referred to herein as viewers regardless of 
whether they are listening, viewing, or both. 

Continuing with Fig. 4. a plurality of disk drives 112 
are provided in the loops 110 represented in the figure 
as small ovals. Additionally, a set of loop adapters 114 
are provided represented as black rectangles in Fig. 4 
which connect each computer 94-108 to each loop of 
the disk communications loop 110. Typically these 
would be SSA or FC-AL adapters dependent upon 
which loop architecture for the loop 110 is adopted. 

Stored media titles are preferably divided into thou- 
sands of data blocks, each in the implementation herein 
described of a size at least 256K bytes. Preferably in- 
dividual data blocks are not stored on a single disk 112, 
but rather are placed in a balanced fashion across many 
or even all of the available disk drives 1 1 2 on the shared 
loops 110. This permits any stored title to be playea si- 
multaneously by a large number of AA/ devices S3 with- 
out overloading any single drive 112 or server 94-108. 
Whereas for illustrative purposes the content on the 
drives 112 has been described as video or movie data, 
the invention is not intended to be so limited. Essentially 
any multimedia, audio, video, or audio/video titles or 
clips may be stored on the shared disk drives 112 and 
in any of a number of digital standard formats including, 
but not limited to MPEG 1 , MPEG 2, and motion JPEG. 
Connection from any of these titles to any such AA/ de- 
vice 83 may thus be made from any of the servers 



94-108 through the isochronous connection 88-82. 

A pair of redundant, fault-tolerant control servers in 
a computing cluster 84-86 are further included for, as 
but one function controlling the servers 94-108. How- 

s ever, control commands may also be set essentially by 
any type of computer or input mechanism capable of 
communicating title selection and play control com- 
mands to the servers 94-108. Either the control server 
84-86 or the A/V servers 94-108 may perform the addi- 

io tional function of balancing the computer load among 
the servers as previously noted. A program executing 
in the control servers 84-86 also performs the additional 
function of determining whether new media selection re- 
quests can be played without pauses, gaps, or exces- 

*s sive loss of quality of service (QOS) to the viewer. If they 
cannot be so played, the control servers will delay the 
request. In the alternative, the programs associated with 
the control server could reside on one or more of the A/ 
V servers 94-108. 

20 One or more archive servers 1 08 preferably may be 
interconnected to a robotic media archiving system 117 
comprised of a magnetic tape or CD ROM media 118 
and a picker 1 1 6 for selecting and playing back tapes or 
CD ROMs in the subsystem 117 in response to com- 

25 mands from the archive server 108. The archive server 
108 will provide the function of loading new titles onto 
the disks 112 of the loops of the shared loop 110. Two 
more clusters may be connected to the archive server 
108 if desired 

30 The operation of the preferred sequence of events 
of the system of Fig. 1 may be more clearly understood 
now with reference to the flow diagram of Fig. 5. This 
flow diagram may be implemented in program code ex- 
ecuting on the control servers 84-86 or A/V servers 

35 94-108 and cause execution of the following steps. The 
control routine is entered at 120, whereupon the typical 
sequence of events in order to play a media title tran- 
spires as follows. First, a request to play a media title, 
1 22 is made by an A/V device 83 (Fig. 4) or a viewer via 
a Network Gateway 80 (Fig. 4) or any other data entry 
device, such request being delivered to the control serv- 
er 64-86 from the Network Gateway 80 along commu- 
nication path 81. The control server(s) 84-86 will then 
determine if the requested title is available, step 1 24 of 

-5 Fig. 5, on any set of the shared loop disks 11 2 of Fig. 4. 
If not. the flow exits to the right of decision block 124. 
whereupon the control server issues a request to the 
archive server 108 along the control message path 90 
of Fig. 4 to load the title onto free disk space in the loops 

so no. If the title is already available on a loop, the flow 
exits to the left of decision box 124. It will be noted that 
the archive server 106 can double as a hot standby to 
A/V servers 94-106 if necessary. 

Next, the control server 84-86 selects an A/V server 

55 94- 1 08 to play the request, 1 28. balancing the workload 
across all of the A/V servers. Because the A/V servers 
are connected to all of the disks 112 via the shared loop 
architecture of loops 110, any A/V server may be select- 
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ed by the control server at any time to effect such play- 
ing thereby making load balancing easier. 

' The control server 84-66 issues a play request, 130, 

to the selected A/V server 94-108 utilizing the control 
message path 90 (or redundant control path backup 92). 
The control message path 90 is preferably redundant, 
although implementations may vary (e.g., Ethernet. FD- 
Dl or Token-Ring paths would be equally acceptable). 

Continuing with Fig. 5, the particular A/V server se- 
lected at step 128 thereafter completes a connection, 
1 32 to the requesting A/V device 83 via the isochronous 
network 88. if such a connection has not already been 
established previously. This selected A/V server will 
then locate the first two blocks of media data (e.g., the 
title data) on the shared loop disk drives 112. and will 
pre-fetch them both into the selected server's memory, 
shown at step 1 34. Next, this A/V server will output the 
first block of the media data via an I/O adapter (e.g., an 
ATM adapter in the server, although not necessarily an 
ATM adapter) which is connected to the requesting A/V 
device 83. This step is shown as step 136 in Fig. 5. 

Next a check may be made of the integrity of the 
ensuing data transfer, 138. The selected A/V server, 
control server 84-86. and communications adapter in 
the server jointly may make checks to ensure that the 
media data flows to the selected A/V device 63 w.thout 
qaps pauses, or the introduction of unacceptable ex- 
cessive noise or jitter. Next, the selected A/V server will 
ore-fetch successive title data blocks into its memory, 
140 prior to their being required by the A/V device 83. 
The' access pattern is preferably essentially random 
across multiple disks 112 and within each such disk. 

Finally when the last media block has been played, 
the title play is ended, whereupon connection to the A/ 
V device 83 is disconnected, 142. A return 144 is then 
issued back to the calling program. 

A summary of several important features and ad- 
vantages of the system herein described now follows^ 
First it has been noted that each disk 11 2 is connected 
to each A/V server 94-1 08 via one or more shared com- 
munication loops shown collectively at reference nu- 
meral 110 of Fig. 4. such loops being implemented via 
SSA or FC-AL architecture and standards. Each media 
selection or title, because of the foregoing design, may 
be directly accessible by every A/V server 94-108 .n the 
cluster or clusters of server computers due to this 
shared disk loop architecture. Media titles may be ran- 
domly dispersed across many such disks 112. thereby 
facilitating individual titles be.ng played by many s.mul- 
taneous viewers. 

Still further, the archive server 108 may load new 
titles directly onto the shared loop disks 1 1 2 w.thout add- 
ing additional workload to any of the active A/V servers 
95 1 06 thereby enhancing the chances of a h.gh quality 
playback. By using a relatively large archive server 108 
with triple SSA or FC-AL loop adapters, it may be ad- 
vantageous to provide not one shared loop cluster as 
shown in Fig. 4. but rather three independent A/V 



shared-loop clusters which may be interconnected, 
thereby reducing archie device, robot, andmed.a costs 
per upload. Moreover, the archive server 108 rtselt can 
assume the workload of afailed A/V node in the cluster, 
thereby acting as a hot standby for up to three intercon- 
nected clusters. In such eventuality, the arch.ve upload 
should nevertheless be delayed long enough to correct 
any A/V server problem. The programs executing in the 
control servers 64-86 desirably may also support multi- 
ple control and data path interconnected clusters (e.g., 
clusters of clusters) for load leveling and scaling to a 
larger number of A/V playbacks. For example, cost per- 
formance studies have shown that disk sharing by 8-16 
A/V servers may amortize shared disk cost enough so 
that additional costs per stream are dominated by non- 
shared system cost. Accordingly, currently there may be 

little economy in scaling clusters beyond 16 nodes. 

Similarly, cost comparisons have indicated that cur- 
rently shared-loop architecture costs considerably less 
per play than comparable architectures using switch-at- 
tached disk drives (Fig. 2) or switch-attached computers 
with local disk drives (Fig. 1). The loop switching in ^ac- 
cordance with the teachings of the invent.on effect.yely 
provides much cheaper switches and is more cost el- 
ective in part because the adapters powered and sup- 
ported by the A/V server 94-108 themselves and the 
disk logic effect the switching and the interacts be- 
tween play streams is small. In currently feasible imple- 
mentations, single shared-loop clusters may readily be 
scaled up to handling on the order of 1 ,000 to 5.000 3 
megabyte per second video play streams with only 16 
A/V servers. Moreover, clusters of such shared loop 
clusters 110 may be scaled to support nom.nally up to 
25 000 streams if desired, assuming suitable sw.tch.ng 
devices for the play streams. Up to three such clusters 
can thereby share expensive archive server and meda 
costs, thereby further reducing the cost per upload 

The invention admits to yet additional benefits as 
well The archive server 108 may load new titles directly 
onto the shared-loop disks 1 1 2 without adding subs an- 
tial workload to any of the active /W servers 94-106. 
thereby enhancing the probability of high qualrty play- 
back which is highly desirable in commercial video-on- 
demand settings. Because all nodes are connected to 
a,| disks and titles may be spread 
all disk drives, suddenly popular, e.g., "hot titles may 
not cause transient system overload on any single serv- 
er or disk drive. 

Still further, replication of data across . muttp e 
l0 ops, plus attachment of each A/V server 94-10 Mo 
each oi such loops results in the fact that d.sk or loop 
failure will have low impact on system play P^ 0 '™"^ 
Still further, as noted, storage cost is a dominant actor 
fn overall cost per played title for many A/V a PP ca*o n. 
The invention contemplates collection by the control 
servers of view frequency per title dafc. Th.s ctet . may 
then be used to optimize shared-loop bandw.dth and re- 
duce data repletion significantly. Still further, dynamic 
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balancing of media title requests across disks 112 is not 
required unless frequency of play optimization is desired 
and utilized. 

White the invention has been shown and described 
with reference to particular embodiments thereof, it will 
be understood by those skilled in the art that the fore- 
going and other changes in form and detail may be 
made therein without departing from the spirit and scope 
of the invention. 



Claims 

1. A method for providing efficient multimedia datast- 
reams in a multimedia system having a plurality of 
A/V servers, and a plurality of storage devices, said 
method comprising: 

interconnecting said storage devices in a 
shared communication loop; and 

interconnecting said A/V servers to said loop. 

2. The method of Claim 1 wherein said loop is an SSA 
or FC-AL loop. 

3. The method of Claim 1 wherein said system in- 
cludes a control server means interconnected to 
said A/V servers and wherein said method further 
includes: 

controlling said A/V servers and said shared 
communication loop with said control server 
means. 

4. The method of Claim 3 wherein said shared com- 
munications loop is a plurality of raid disk arrays. 

5. The method of Claim 3 wherein said system further 
includes archive server means controlled by said 
control server means, and archive storage system 
means interconnected to and controlled by said ar- 
chive server means, and wherein said method fur- 
ther includes: 

accessing data on said archive storage system 
with said archive server means: and 

distributing said accessed data onto said 
shared communication loop with said archive 
server means. 

6. The method of Claim 5 further including: 

detecting an error associated with one of said 
A/V servers: and 

substituting said archive server for said one of 
said A/V servers in response to said detecting 



said error. 

7. The method of Claim 6 further including: 

s generating one of said datastreams by one of 

said A/V servers from said shared communica- 
tion loop: and 

distributing said one of said datastreams onto 
io a communication network in said multimedia 

system by one of said A/V servers. 

8. The method of Claim 7 wherein said A/V servers 
are interconnected to said shared communication 

'5 loop in said control server means controts said A/V 
servers and said plurality of storage devices to pro- 
vide substantially equal access to any of said stor- 
age devices on said shared communication loop by 
any of said A/V servers. 

20 

9. An apparatus for providing efficient multimedia da- 
tastreams in a multimedia system having a plurality 
of A/V servers, and a plurality of storage devices, 
said method comprising: 

25 

means for interconnecting said storage devices 
in a shared communication loop: and 

means for interconnecting said A/V servers to 
30 said loop. 

10. The apparatus of Claim 9 wherein said loop is an 
SSA or FC-AL loop. 

3$ 11. The apparatus of Claim 9 wherein said system in- 
cludes a control server means interconnected to 
said A/V servers and wherein said method further 
includes: 

means for controlling said A/V servers and 
40 said shared communication loop with said control 
server means. 

12. The apparatus of Claim 11 wherein said shared 
communications loop is a plurality of raid disk ar- 

45 rays. 

13. The apparatus of Claim 11 wherein said system fur- 
ther includes archive server means controlled by 
said control server means, and archive storage sys- 

so tern means interconnected to and controlled by said 
archive server means, and wherein said method 
further includes: 

means for accessing data on said archive stor- 
es age system with said archive server means: 
and 

means for distributing said accessed data onto 
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said shared communication loop with said ar- 
chive server means. 

14. The apparatus of Claim 1 3 further including. ^ 

means for detecting an error associated with 
one of said A/V servers, and 

means for substituting said archive server lor 
said one of said A/V servers in response to said 
detecting said error. 

15. The apparatus of Claim 14 further including: 

means for generating one of said datastreams « 
by one of said A/V servers from said shared 
communication loop, and 

means for distributing said one of said datast- 
reams onto a communication network in said 
multimedia system by one of said A/V servers. 

16 The apparatus of Claim 1 5 wherein said A/V servers 
are interconnected to said shared communication 
,oop in said control server means controls said A/V 
servers and said plurality of storage devices to pro- 
vide substantially equal access to any of said stor- 
age devices on said shared communication loop by 
any of said A/V servers. 

a multimedia datastream system including at least 
one A/V device, a plurality of A/V servers, an ar- 
chive server, and a shared loop storage subsystem, 
comprising the steps of: 

generating a request from said at least one N 
V device to play a title: 

checking to determine if said title is available 
on said shared loop storage subsystem: 
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requesting said archive server to load sa.d rile 
in response to said check indicating said trtle is 
not available on said shared loop storage sub- 

system; 

selecting one of said plurality of A/V servers to 
play said request: 5Q 



issuing said play request to said server. 

making an interconnection from said A/V server 
to said one A/V device. 

locating an prefetching blocks of data of said 
datastream stored on said shared loop storage 
subsystem by said A/V server. 



55 



14 

outputting an initial portion of said data com- 
prising said datastream from said shared loop 
storage subsystem; 

checking data transfer integrity of said first por- 
tion of data : 

transferring said first portion of data from said 
A/V server to said at least one A/V device: 

prefetching successive next portions of data 
comprising said datastream from said shared 
toop storage subsystem by said A/V server: 

checking data transfer integrity of said next por- 
tion: 

repeating the immediately preceding two steps: 

checking for fetching of a last portion of said 
datastream: and 

disconnecting said connection after said check 
for said last portion of said datastream. 
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